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(54) Document delivery system 

(57) A document delivery system delivers an elec- 
tronic document between a sending computer (16) and 
a receiving computer (22). A server (12) is inteiposed 
between the sending computer (16) and the receiving 
computer (22). When an electronic document is for- 
warded to the server (12) from the sending computer 
(16) the server (12) dynamically generates a private Uni- 
form Resource Locator ("PURL") to distribute the elec- 



tronic document The intended recipient (22) of the 
document uses the PURL to retrieve the document. The 
server (12), upon retrieval of the document, customizes 
the behavior of the retrieval based upon attributes 
included in the PURL A method and system are pro- 
vided for secure document delivery over a wide area 
network, such as the Internet. 
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Description 

The invention relates to the field of computer networte. 

The development of computerized information sources, such as those provided through the Internet or other on- 
5 line sources, has led to a proHferation of electronically available Information. Currently, a user who subscribes to the 
Internet manually navigates through the Internet to visit sites which may or may not be of interest. 

An inherent problem in this Intemet system is that the available infonnation is distrftxrted through a "pull" type infra- 
structure, where the user who wants to receive intornrHtion must manually search sites of interest, or use a finder appli- 
cation, to search and download appropriate information. For a user who wishes to publish and distribute information or 
10 documents, either an individual or a larger entity that has information that is desired to be distributed, the present 'putr 
system doesnl allow the freedom to send and distribute to a redplent or group of recipients, in a *t)ush'' fashion. 

Facsimile technology is widely used at the present time for the distribution of simple documents, but has numerous 
drawbacks. Including lower quality printed documents, costly and bulky paper copies (particularly if the recipient doesnl 
care to have a paper copy), toss of content (ag. text and graphics cant be edited or manipulated), and time require- 
15 ments for transmission, particularly fbr long or complex documents. 

Electi-onic Mail (E-mail) provides a means for sending electronic messages from computer user to another. E-mail 
has advantages of convenience, forniat and storage of messages fbr later retrieval. As su^. E-mail has been accepted 
and widely used for basic communication. E-mail is typk»lly an ASCII based format, however, and proves to be very 
limiting for the communication of long or formatted documents. As weU, E-mail Is not the medium of choice for the dis- 
20 tribution of complex documents, such as reports, articles, advertisements and art which can include page layout grids, 
postscript-formatted objects, multiple fonts with tracMng and kerning, graphics, imbedded tables and spreadsheets, and 
other complicated infbrmation. Some E-mail systenrs provide a means for appending an ASCII based E-mail message 
witii an associated file, to be downloaded along with the E-mail message. Most systems that allow the appending of an 
associated f 9e are designed to alfow a single user to send unsecured files to an associate or friend, and neitiier allow 
25 fbr controlled automated distribution to multiple redpienls. nor do they provkle advanced accounting. biUing or other 
such features (e.g.. receipt notifk»tion). E-mail gateways also Umit the appOcabUity of attachments, and do not solve tiie 
problems of security and receipt notation or acknowledgment. 

C. Baudoin, Interenterprise Electronic Mail Hub. U.S. Patent No. 5,406.557 (1 1 April 1995) discloses an interenter- 
prise communications center, which has a computer hub con^ising a common core and a plurality of input and output 
30 modules. The input modules connect to a first end user, and convert a message sent by the first end user into a univer- 
sal format. The hub core queues the message and fomvards it to the output module fbr conversfon into ttie fomiat of the 
destinatton user. While the disctosed hub discloses technkiues to relay simple e-maii messages, it is designed to con- 
vert ttie e-mail message famats, thus losing the integrity of ttie original texlbased f ae. 

The disctosed prior art systems and methodologies thus provide some mettKXls for the delivery of documents, but 
35 fail to provide an economk»l, fast document delivery system that operates in a push-fashion, while conserving ttie 
integrity of the original electronic f fle. The devetopment of such an electronic document delivery system wouki constitute 
a maja technological advance. In addition, the ability to distribute eledronic portable high content- quality documents 
to many recipients in a controlled, econonrvcal and accountable foshfon wouU constitute a further technologk»l 
advance. 

40 The Internet is increasingly being used for communications. It is now possible on the Intemet for a sender to direct 
a document to a specif fo recipient, regardless of platfonn. operating system, or email system. The sender's con^uter 
may be connected to the Intemet directiy, or through an IntraneTs server. Such communication is possible even when 
the recipient is not a computer but. rather, a fax machine or printer connected to the Internet. 

This increase in Intemet communications has necessitated the development of security systems to insure protec- 

45 tion for Information transmitted over the Internet. 

Encryption is a basic technique used to scramble information to prevent unsolicited access to that informatton. One 
well-known encryption scheme is secret key encryption, sometimes referred to as private key encryption or symmetric- 
k^ cryptography. Secret key encryption employs the technique of scrambling information using a unique key to prevent 
unsolicited access thereto. This unique key is then required to unscramble the information. Figure 1 is a diagram illus- 

50 trating secret key encryption, according to the prior art. 

A document 1010 s scrambled 1012 using a seaet tey 1014. A seaet key is an encryption scheme that is only 
available to authorized users of the scheme. The encryption software may be focated on the user's computer, or at a 
remote location. Thus, ttie document may be encrypted in situ, or upon transmissfon to another computer, such as an 
intranet server. 

55 The resulting encrypted documem 101 6 Is tiien transmitted to the recipiert. It is unsCTa^ 1018 using tiie secret 
key 1014 to regenerate the original document 1010. The enwypted document cannot be accessed without the seaet 
key. Again, ttie decryption software may be located on the recipient's computer, or at a remote tocation. 

One potential problem associated with secret key encryption is ttie secure distrfoution of the seaet key. If the seaet 
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key 18 sent over a non-secure channel, the integrity of the security is ooniproniised. For nx>st practical apptlcations. teN 
ephone or fax provides adequate security for delivering secret keys, while the docunient can t>e delivered over the inter- 
net using such mail schemes as Posta. which is available from Tun^leweed Software Corporation of Redwood City. CA. 
in some instances, however, users require a more secure, or mae convenient, means of distributing a key. 

5 Another known encryption scheme is pubiic key encryption. In public key encryption, the sender and the recipient 
each own a pair of keys, called the public key and the private key. The owner of a k^ pair publishes the puUfo key and 
keeps the private key a secret. 

The sender uses the published publk; key of the intended recipient to encrypt informatk>n. The information is 
decrypted using the recipient's private key. Th^ using public key encryption, no private key must be distributed. 

TO Figure 2 is a diagram illustrating public key encryption, according to the prior art. A document 1020 is scrambled 
1 022 using a public key 1 024. The resulting encrypted document 1 026 is then transmitted to the recipient It is unscram- 
bled 28 using the private k^ 1030 to regenerate the original document 1020. 

The keys used in public key encryptfon are very large numbers. Public key encryptfon exploits an esoteric mathe- 
matical relationship between the key numbers to inpiement the encryption and decryption. As a result, the private key 

75 cannot readily be derived from tfie published pi^ic key. 

It is often useful to verify that a document has not been altered during transmissfon, or to verify the sender or redp- 
i^ of a document. Secret and public key technofogy provide such verification. However, public key encryption algo- 
rittims are typically complex and often are too time consuming fo be of practical use. Secret key encryption is much 
faster, but there are difficulties associated with securely transmitting the key. 

20 A public keyA>rivate key encryption system is described in Ganesan, Vbksha. An Improved System And Metiiod For 
Securing Communications Using Split Private Asymmetric Cryptography. U.S. Patent No. 5.535.276 (9 July 1996). 
However, the Ganesan encryption s^ieme uses a complicated scheme for generating temporary keys and requires 
several different users to manually request public keys. 

In Torii . Key Distrfoution Protocol For File Transfer In The Local Area Networic. U.S. Patent Nto. 5,313.521 (17 May 

25 1991)akeydistributioncenteri8U8edtDauthenticateaterminaltoa8erver. Pasfor, Reliable Document Authentication 
System. U.S. Patent Ma 4.853.961 (1 August 1989) describes a document auttientication system that includes a 
decryption key. Choudhury. et al. Method of Protecting Electronically Published Materials Using Cryptographic Proto- 
cols. U.S. Patent No. 5.509.074 (16 April 1996) teaches a document protection system that includes a sen^er-to-server 
security access operation to authenticate each document request However, all of these prior art schemes require user 

30 intervention to authenticate the certificate. 

Anottier encryption scheme, digital envetopes, Is not subject to the disadvantages of secret key and public key 
encryption. Using digital envelopes, a sender encrypts a document with a seaet key. The seaet key is then encrypted 
with a public key. The recipient of ttie document then uses the recipient's private key to decrypt the secret key. and then 
the secret key to decrypt tiie document 

55 Registries are now available for pubik»tion of pubOc keys. Such registries can certify that a particular public key 
belongs to a particular entity. For example, a certificate authority issues and maintains digital certificate that are used 
to connect entities to their specif fo public toys. The sender must query ttie registry to receive the requested publfo key 
infomiation. This time-consuming process is inefficient, especially when ttie sender has a large number of documents 
to transmit to different recipients. 

40 It is tiierefore the object of the presont invention to overcome ttie drawbacks and disadvantages of ttie prior art This 
object is solved by an apparatus for delivering an eiectrorac document according to independent daim I. a document 
delivery system and a mettiod for delivering an electronfo document according to independent claims 12 and 30. meth- 
ods and systems for secure document delivery according to independent daims 37. 48. 54 and 63 respectively. 
Furttier advantageous features, aspects and details of ttie invention are evident from ttie dependent claims, 

45 desCTiption and drawings. The daims are to be understood as a first non-limiting approach of defying the invention in 
general tenns. The invention relates to techniques fbr ttie delivery of electronic documents to users over ttie Internet. 
Furttier. ttie invention relates to a mettiod and system for provkling secure document delivery over a wide area networic. 
such as ttie Internet. 

It is an advantage to provide a system and method for automatically and dynamically retrieving a public key over a 
50 wide area networic for encryption purposes. It is a furttier advantage if such system and method uses a server to retrieve 
the certificate and requires no user intervention. It is yet anottier advantage if ttie system and mettiod does not transmit 
a document to the server until ttie server has retumed the public key to ttie user. 

An electronic document delivery system and mettiods of its use are provided. A document delivery architecture 
dynamically generates a private Uniform Resource Locator (URL) to distribute information. Each private URL ("PURL") 
55 uniquely identifies an intended recipient of a document, ttie document or set of documents to be delivered, and option- 
ally ottier parameters specific to the delivery process. The intended recipient of a document uses ttie PURL to retrieve 
the document. The sender, upon retrieval of the document customizes ttie behavfor of ttie retrieval based upon 
attributes induded in ttie PURL, as well as log Infbrmation associated witti ttie retrieval in a data base. This architecture 
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and usage of PURLb enablas secure document delivery and tracking of document receipt 

The Invention provides a method and system for secure document delivery over a wide area network, such as the 
Irtemet A document is sent from sender to recipient via a Delivery Server. In the prefen-ed embodiment of the inven- 
tion, the Delivery Server is directed by the sender to retrieve the intended redpients public key (certificate). The Deliv- 
ery Server dynamically queries a certificate authority and retrio/es the public key. The public key is transmitted from the 
Delivery Server to the sender. 

The sender encrypts the document using a seaet key. The secret key is then encrypted using the public key. Both 
encrypted document and encrypted secret key are uploaded to the Delivery Server, and transmitted to the intended 
recipient. The intended recipient then uses the private key associated with the public key to decrypt the secret key. and 
uses the secret key to decrypt the document. 

In an alternative, equally preferred embodiment of the invention, the sender uses the public key to enaypt the doc- 
ument. The encrypted document is then transmitted to the intended recipient and decrypted using the private key asso- 
ciated with the public key 

In yet another embodiment, the sender transmits the document to the Delivery Server tor encryption. The Delivery 
Server queries the certificate authority in real time to retrieve the public key. The Delivery Senrer encrypts the document 
using a secret key. and then uses the public key to enaypt the secret key. The Delivery Server then transmits the 
encrypted document and the encrypted secret key to the intended recipient 

In the event that the Delivery Server query returns failure (no certificate available for the given user), the Delivery 
Sender dynamically generates a new publk: key for ttie intended recipient. This new certificate is then used to enaypt 
the document 

Figure 1 is a diagram Illustrating seaet key encryption according to ttie prior art: 

Figure 2 is a diagram illustrating public key encryption according to ttie prior art; 

Figure 3 is a block diagram which depicts a binary file delivery system using one binary file sender; 

Rgure 4 is a block diagram which depicts a binary file defivery system using two binary file servers; 

Figure 5 is a block diagram which Olustrates key elements of a store item; 

Figure 6 is a schematic depkrtion of ttie binary file delivery server; 

Figure 7 provides an example of the architecture of one embodiment of ttie binary f fle server; 

Figure 8 illustrates different types of store events employed tiy ttie binary file delivery server; 

Figure 9 ts a thck diagram of the specific components wtthin the binary file delivery server archhecture; 

Figure 10 provktes a block diagram illustrating of ttie architecture of ttie store; 

Rgure 1 1 illustrates how ttie user session organizes internet clients into ttiree layers, including sessions, transac- 
tions, and transports; 

Rgure 12 illustrates ttie non-interactive tasks of a delivery, once ttie send sesston has aeated a store item or 
another server is fbnfvarding a store item; 

Figure 13 provkles details of ttie account manager architecture; 

Figure 14 provMes details of ttie k)gger architecture; 

Figure 1 5 provkfes details of ttie server connector architecture; 

Figure 16 provkles a functional block diagram which depicts a portable document deRvery system using one port- 
able document delivery server; 

Figure 1 7 provides a functional block diagram which depicts a portable document delivery system using two port- 
able document delivery servers; 
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Figure 18 illustrates horn a portable document send client application and a portable document receive client appli- 
cation are used in the invention; 

Figure 19 illustrates hew a server configuration user interface application is used In the invention; 

Figure 20 Illustrates how a document can be sent by the fax gateway of a server to a printer; 

Figure 21 illustrates how a document can be sent by the department gateway of a defeated corporate server 
through a LAN to a department printer; 

Figure 22 is a block diagram which depicts a document delivery system that Includes private, trackable URLs for 
directed document delivery according to the invention; 

Figure 23 is a diagram illustrating dynamic sender document encryption according to a first preferred embodiment 
of the Invention; 

Rgure 24 is a chart of the set of operations for dynamic server document encryption according to a first pre- 
ferred entxxliment of the invention; and 

Figure 25 is a f bw chart of the set of operations fbr dynamic server document encryption according to an altema- 
tive embodiment of the invention. 

The binary file delivery system 10 enables corporations, publishers and individuals to distrSxite documents elec- 
trontcaliy. Importantly, unlike existing Wfeb based document publishing technologies, the binary file delivery system 10 
allows the directed and secure dislributkxi of documents. The Web oouM currently be characterized as a pull-publlsHng 
environment, where the consumer of documents must find and retrieve documents from a server. Push-publishing, by 
contrast, allows the producer of a document to direct the delivery of documents to consumers. Facsimile (fax), the 
postal service, and electronic mail (E-mail) are ail examples of push-publishing. 

Figure 3 is a block dla^am which depicts a binary file delivery system 1 0 using one binary file server 1 2. The binary 
file delivery system 10 allows users to push documents, enabling the producer of documents to direct where those doc- 
uments will go. One way that the binary file delivery system 10 achieves push-publishing is by combining HTTP, which 
is usually implemented to pull Information over a network, with SMTP (wNch only supports text). Additionally, the binary 
file delivery system 1 0 provides a host of services to facilitate the various applications of directed document delivery. At 
one level, the binary file delivery system 10 can be characterized as a new generation of facsimile technology, which 
utilizes networks instead of telephone lines, and moreover, introduces support fbr new document representations vastly 
superior to existing fax formats. At another level, the binary f Se delivery system 1 0 is a general purpose document deliv- 
ery server capable of supporting massive amounts of documents and transactions. In all cases, the binary f Be delivery 
system 1 0 provides a complete and robust solution fbr document delivery. 

The binary file delivery system 1 0 is used for sending a set of binary files from one end-point to one or multiple end- 
points. An endpoint is typically a recipient 22 with Internet access, but can also be another entity, such as a facsimile 
machine 172 or a printer 178 (Figs. 16. 17). The delivery of binary files is accomplished in a reliable, accountable, and 
tractable manner. The binary file delivery system 10 provides several levels of security fbr the directed files, from E-mail 
equivalent security, to better than facsimile or physical mail. The system also provides user account management 
including the credit and debit of billing accounts. The system can also cooperate between mult^^le binary file delivery 
servers 12. which may or may not be controlled by some other authority. Figure 4 depicts a binary file delivery system 
using two binary file servers 12a and 12n. which communicate across an Internet 

The binary file delivery server 12 operates in three primary modes, which include a public mode, where senders 16 
set up their accounts 1 32 themselves and are subject to billing, a private mode, where senders 1 6 are controlled by an 
administrator, and billing is wore an intemal accounting issue than a collection issue, and a publishing mode, where 
there are many recipients 22. but few senders 16. 

The binary file delivery server 12 is corrprised of separate functional components, and are not necessarily proc- 
esses or shared libraries. The binary file delivery sen/er 12, shown schematically in Figure 6. Includes an intelligent 
storage compartment called a store 42. which is augmented by a set of clients 44a-44n, called store clients 44, which 
use the store methods and listen to the store events, but do not interact with or loiow about other clients 44. An account 
manager 46 corrponent is a shared service that keeps information about the sender 16. The design also incorporates 
information about recipients 22 for the case of a receive application (as opposed to e-mail notification). 

The client/server gene-al architecture provides a better extensibility than a more pipelined structure. It also decou- 
ples the store clients 44 from each other, which can be useful in the context where some tasks are interactive, while 
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others are more background oriented. 

The Store. The store 42 contains a set of store Items 48. As shown In Figure 5. a store item 48 includes a tree of 
binary files 34 and a descr^jtor 36. which Is a set of store-defined and client-defined attributes. The tree of binary files 
34 can be viewed as part of the store^iefined attributes. 

The file storage system provides the following fiinctionallty : 

1) Pennanent storage of Store items 48 (e.^. the binary file tree 34 contained in a store Item 48 is written to disk) 

2) Client read/Write access to the descriptor 36. which is made up of store-defined and client-defined attributes 
(e.g. a dlent 44 can write the expiration date of a store item 48) 

3) CUent notification of stae events 67 {e,g. clients 44 can be notified of the aeatk)n event 68 of a new store item 
48) 

4) Internal management according to store defined attributes (e.g, store Item ovxration date generates an event). 

The store 42 provides access to the store items 48 and generates store events 67, wherein store items 48 have 
store-defined attributes such as ID. creation date, file count file names, file data, and store events 67 can be listened 
to by the clients 44. Store events 67 may include the creation 68. deletk)n 69 or modification 70 of a store Item 48. TTie 
events 67 play a crucial role in the architecture, since this defines how the dients 44 synchronize their woric with a very 
limited knowledge of the other. 

Store Clients. Store dients 44 can be of a wMe variety, and specific dients will be detailed further. In this f rame- 
worK a store dient 44 is some component which uses some of the store methods and or listens to some of the store 
events 67 to periorm useful tasks on the store items 48. 

Account Manager. The account manager 46 provides read^vrite access to user and billing accounts, and Is used 
by dients 44 or other components of the system 10. The store 42 does not use or know about the accounts. 

Other Components. Other components used by the store dients 44 and the 
the architecture of the system. For example, interserver oommuntcatton. log management, and other-administrative 
services, which is discussed below. 

Figure 7 provides an example of the architecture of one embodiment of the binary file server 42, Induding client 44 
modules (52-66) that are used to implement sen/er functions. The Internet Send 52 is used to create store items 48 and 
fills In the attributes. The Internet Receive 54 opens existing store items 48 and can be used to modify their attributes. 
A Fax gateway 56 listens to the aeation events 68 generated by the store 42. processes relevant store items 48, and 
then deletes them from the store 42. A fonivarder 58 listens to the creation events 68 generated by the store 42. and 
then examines the attributes of the new store items 48. and deddes if forwarding Is necessary. An archiver 60 listens 
to deletion events, and copies the stae item 48 to secondary private storage before deletfon occurs. The format trans- 
lator 62 listens to creation, examines attributes, and if translatfon is needed, it reads, processes and writes back the files 
in the store item 48. The web publisher 64 listens to the aeatran events 68 and checks if the store item attributes spec- 
ified a Web publishing, and if so. read the attributes as necessary. A pickup notlfier 66 listens for a aeation event 68. 
and then notifies recipients 22. 

Security Issues for Internet-based Users. While the Binary RIe Delivery System 10 offers the flexibility to sup- 
port spedaUzed security sdutions. it readily supports current industry-standard security sdutfons. Induding: 

a) secure server interconnect and server authentication (available with SSL 2.0. whteh Is built into the servers 
(HTTP); 

b) secure Server-to-Senrar (on top of SSLX); 

c) support end-pdnts private key (the private key has to be exchanged by the users using their own channels: 

d) support end-points public key, using CryptoAPI or the standard user public key. The system can also help the 
user generate a public key for BFD-use only, and update user account Infonnation with it, so that the sender does 
not have to communicate directly with the redpient to get the public key; and 

e) aient Authentication by the server with SSL and MS PCT (End user can get their own certificate and be authen- 
ticated by the servers). 

An important aspect of the binary file delivery server 1 2 is that it handles multiple requests in parallel and minimizes 
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the response time for most requests. Therefore, synchronization issues are important, for both correctness and system 
performance. Performance is enhanced by minimizing synchronized data access, defening to asynchronous process- 
ing whenever possible, and by using muftitasking and Inter-Process Communication (IPC) tor the piattorm. One entxxJ- 
iment of the server 12 relies heavily on threading, which provides low overhead muHitasKing within one process, and 

5 leverages multiprocessa capabilities when available. The IPC on this errbodiment uses named pipes, in addition to 
mail slots or Remote Procedure Call (RPC). 

Figure 7 provides a block diagram of the specific components within the binary file delivery server 12 architecture. 
The user session 72 handles send sessions, receive sessfons (which are implemented when the user is using a 
BFD desktop applicatfon 192. 198). HWiL receive sessions (which are implemented through an HTML browser, as 

10 opposed to when the user is using the BFD desktop 164 (note that a BFD desktop session may go through HTML)), 
maintenance sessions (which irrplement the account setup and maintenance sessions (e.^. notification downloads, 
account setting modificatfons (not to be confused with console services by an administrator, as opposed to an end user 
of a public server). HTML maintenance sessions (whk:h Implement the account setup and maintenance through an 
HTML browser). 

IS A delivery component 74 implements the background work of making a delivery, mduding notification and forward- 
ing. A console 76 is used to implement administralfon sessions, which are conducted through an HTML interface 
instead of a specialized user interface. The console 76 provides a user interface to browse and modify alt the server 
properties, including accounts, logging, perfomiance. and parametor settings. 

Shared Components. Shared components may be used by the store 42. by any of the store clients 44. or they may 

20 operate on their own. While they do not listen to store events 67, they can use store methods, as needed, for efficiency, 
such as for connector receive). Shared components may include: 

1) An account manager which maintains all local account infbnnation and provkies a unkiue access interlace to 
local accounts, including billing account and remote account infonnation; 

25 

2) a sender connector 80, which handles all inter-senfer communications: 

3) a mail gateway 84, which handles the sending and receiving of bounced mail; 

30 4) a logger 86. which manages access read/write to the different logs which are classified by a type. The most 
important log is the send/receive transaction log, which tracks what happens to store items 48 over time: and 

5) an operating system accessor 82. which provides a platform independent interlace to the operating system for 
file Input and output (I/O), process management (synchronization, locking, threads, process). PC (RPC. shared 
35 memory, shared queues, pipes), network access (TCP/IP sockets. HTTP sen^ interfadna POP/SMTP interfoc- 
ing). Specific portions will be implemented as needed. 

The Server Application. The server application 88 is used to start ip and shut down all pieces of the binary file 
delivery server 12. according to the configuration parameters. It also provides tiie administrative aspects of the server 

40 not covered by the Account Manager (46 or 78) or by the Logger 86, such as pertbnnance prof iUng. usage information 
and server parameters/configuration. 

Figure 10 provides a btock diagram illustrating of the architecture of the store 42. A store manager 92 is used to 
maintain global state, to synchronize access to tiie store 42 and to provide housekeeping functions. A store item man- 
agar 94 is used to maintain the state, tocks. and cache mechanism of a store item 48. A store event manager 96 is used 

45 to maintain listener lists and event filters, as well as to dispatch events according to event filters and event priorities. 

Figure 1 1 illustrates how tiie user session organizes intemet clients into ttiree layers, including sessions, transac- 
tions, and transports. The session manager 102 maintains all tiie cunrentty active sessfon states and performs tiie ses- 
sion-related housekeeping, ft processes transactions coming from transaction nranagers 108 ttirough \he uses of tiie 
store 42 and ttie account manager 46. The transaction manager 108 receives raw date from ttie transport rnanagers 

50 1 14, 1 18. and performs validation and preprocessing using one a more BFD transaction interpreters 1 10 or HTML 
transaction interpreters 1 12. The transaction manager 108 ttien submits ttie date to ttie appropriate BFD session man- 
ager 104 or HTML session manager 106. waite for an answer, and ttien passes ttie answer back to ttie appropriate 
transport manager 1 14 or 1 18. 

Rgure 12 illustrates ttie non-interactive taste 120 of a delivery, once ttie send session has aeated a store item 48 

55 or anoflier server 12 a-n Is forwarding a store Item 48. The delivery manager 1 22 likens to relevant store events, makes 
a fbnwarding decision, and coordinates wori^ witti ttie notif ier 66 and the fwwarder 58. The server directory keeps track 
of the association between E-mail domaire and server domains. The notif Ier 66 is used to handle E-mail notification 20 
to the recipient 22. TTie fonrarder 58 Is used to forward store items 48 to ottier servers 12a-n. using a senw connector 
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80. Since not all E-mail notifications may be received, an E-mail scanner is used to check the server mail account for 
"returned" E-mail, and then to match it with the foiled ttansaction. 

Figure 13 provides details off the account manager architecture 130. The account manager 78 is used to maintain 
user account states 132 for the local server 12, to maintain billing account states 134 for the local accounts 132, to 
5 query local accounts 132. and to maintain a directory of remote accounts 136. The primary 
directory 136 Is to associate E-mail addresses with either BFD accounts or non-BFD accounts. 

Figure 14 provides details of the logger architecture. Rgure 15 provides details of the server connector architec- 
ture. 

System Operation. The following example illustrates how the binary ffle delivery system 10 is used to distribute 
10 electronic information from a sender 16 to a receiver 22. A hypothetical publisher. Sam in Redwood City. Califbrnia. 
wishes to send a document to an associate. Rohi in Tol^. Japan. The following progression of events illustrates how 
this is achieved, in a controlled fashion. 

Sam connects to a local server in Santa aara, California. Sam's BFD desktop opens a connection to a local 
sender 12a in Santa Clara, where his user account resides. The session manager 102 queries the account manager 78 
15 to validate the user 16 (Sam). The session manager 102 then creates a send session state for the user 16. 

Sam's Send Session. Sam's BFD desktop sends transaction details, such as the number of files, file size, and 
intended recipients. The session nmiager 102 attaches this data to the session slate. Then tiie session manager 102 
creates a store item 48 descriptor 36 in memory, and reserves disk space with the store 42. as well as a store item ID. 
Then the upload starts. The session manager 102 spools the data directty to a file with asynchronous I/O. 
20 When ttie upload 18 of all of Sam's files is complete, tiie session manager 102 updates tiie store item descriptor 
36 to tiie disk asynchronously, and then inserts the store item 48 asynchronously into the store 42. 

The sesskHi manager 102 anwer's Sam*s upload witti an adoiowledgement, and provkjes information regarding 
the transaction. This session then ends. 

At the Santa Clara Store. The insertion of the store item 48 is logged asynchronously in the logger 86 by the store 
2S 42. The store 42 then runs ttie store item descriptor 36 against the registered event handlers f Uters. For each match, it 
inserts ttie event and notif iee (Rob) in its event queue. Then that ttiread dies. 

The event dispatch thread pulls the events, and dispatches them asynchronously to the notif iee at rate, depending 
on the tuning parameters of the system. 

The Santa Clara Delivery is Notified. The deUvery 74 is notified of a relevant event and starts a thread which waits 
30 on the lock of the store item 48 via a synchronous transaction with the store 42. Once ttie lock is secured, ttie ttiread 
reads the store item descriptor 36, and ttie delivery manager 74 analyzes it. to decide how to handle it It turns out ttie 
recipient 22 is in ttie Japan domain, where anottier BFD sen/er 12n is k)cated. The defivery manager 74 fbund ttiis out 
by querying a sen/er directory 124. The manager ttien deckles to fonwd the store item 48. The forward manager 80 
asynchronously asks the Connector 80 to do a forward to Tokyo. Then ttie thread in ttie delivery dies. Note that ttie 
35 delivery does not know about ttie server protocols. 

The Santa Clara Connector 80 is going to fororard ttie Tokyo Connector 80. A ttiread handling ttie delivery request 
is eventually started in the Connector 80. It knows ttie host, and has a tock on ttie store item 48. It initiates ttie connec- 
tion witti ttie Tokyo server 12n. If it cannot connect, it goes to sleep for a while. EventuaOy the connection opens, and 
the connector 80 enters the protocol interpreter, which eventually transfers ttie store Item descriptor 36 and the assod- 
40 ated binary data files 34, Then it closes ttie connection and logs a successful forward to the Tokyo server 12n in ttie 
logger 86. Then the connector 80 releases ttie lock on the store item 48 in ttie store 42 after having marked it as for- 
warded. 

On release of ttie lock, ttie store 42 runs ttie store item desaipta 36 against ttie event filter list and finds an event 
filter that is handled locally A successfully fonRrarded store Hem 48 causes a reference count decreased by 1 . In ttiis 
45 example, there is only one recipient 22, which means ttie count goes to zero. Therefore, ttie store 42 can move ttie store 
item 48 to a deletion list, A housekeeping ttiread of ttie store 42 will ttien purge ttie Store Item 48 at some point. 

A ttiread in ttie Tokyo connector receiver 80 is begun, to handle ttie connection. Once ttie protocol interpreter 
understands it as a fonward, it asks ttie store 42 for a store item ID 36 and ttie respective committed storage space. The 
actual store item descriptor 36 and files have been written to disk as it was receiving ttie data 
so Once ttie connection is complete, ttie stae item 48 is inserted asynchronously into ttie store 42 of ttie Tokyo binary 
file delivery server 12n. 

Tokyo Delivery Component begins. The Tokyo store 42, on insertion, has generated an event which is going to 
be handled by a ttiread of ttie delivery It has also logged ttie insertion of the new Hem in ttie logger 86. The manager 
102 in delivery 74 realizes ttiis has been fonwarded, and that it will be received from ttiis sender 12n. 
55 The senrer 12n queries ttie account manager 78 to see if ttiere is an account associated witti ttie E-mail address 
of Rob. If ttiere is no associated account witti Rob E-mail, ttien an E-mail is sent to Rob. with an URL which indicates 
the store item ID 36. It also queues an asynchronous request for ttie connector 80 to notify the Sarta Clara sender 12a 
that Rob has been notified. If Rob has an account here, then the delivery pute an asynchronous update request witti 
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the account manager 78 to mention the pending delivery; in thie case the scenario is continued. 

Rob connects to the Tokyo Server to check on new documents. When Rob opens its receive session, the ses- 
sion manager 102 synchronously checks the Rob account tor validity, and In the process ft updates the session state, 
to remember that the account is flagged with a pending receive. The BFD desktop of Rob eventually asks for the doc- 
ument to be received. The sesskm state has the answer and says yes. 

The Rob desktop 170 asks for the receive, and the session manager 102 synchronously asks the store 42 for the 
lock on the relevant store ftem 48. Once granted, it can answer by sending the first portk)n of data. Once the document 
is downtoaded, it asynchronously togs a successful receive with the logger 86. Then it puts an asynchronous request 
with the connector 80 to notify the Santa Clara server 12a of the final delivery. 

At the receive session in Tokyo, the sesston manager 102 releases the lock, and puts an asynchronous delete 
request to the stwe 42. The Rob receive sesston then terminates. The connector 80 in Santa Clara runs the protocol 
interpreter, which says that the notiTications must be queued to the togger 86. 

Sam checks on Status. Sam connects to do a receive sesston followed by a maintenance sesston. The mainte- 
nance session 72 receives a request to check on the slatus of the sent document The maintenance session 72 syn- 
chronously submits a query to the logger 86 using the store item ID 36 that was passed down to the Sam desktop at 
send time. The query returns the lists of matching records, whtoh are processed and passed back to the desktop, which 
can then update the user interface 16. 

Portable Document Delivery System. Electronic portable documents are beconwng inaeasingly popular. These 
files can be distributed to different platforms without tosing their original look and feel. Adobe Systems* Aaobat PDF~ 
and Novel's Envoy^ portable document fomnats have come into wtoespread use. In a pref^ed embodiment of the 
inventton. a portable document delivery system 160 achtoves a universal solution to the delivery of electronic docu- 
ments, by applying portable document technotogy to the IntemeL The portable documemde^ 160provides 
complete compatibility with portable electronto document formats, including Novell^ ENVOV™ and Adobe System^ 
PDF~ formats. 

Recipients 22 of portable documents from the portable document delivery system 160 can view, search, print, 
archive, or export informatton from their documents. Documents distributed using Envoy"^ or Acrobat"" in conjunctton 
with the portable document delivery system 160. presence complete visual fidelity and may be produced on high reso- 
lution output devices with the highest level of quality and resolutton. Portable document formats allow preserve content 
and cotor of the information within a document, and many tomurts allow indexing, searching, and hypertext linking, 
while allowing the file to be stored in a compact manner. 

Figure 1 4 is a functional block diagram which depicts a portable document delivery system 1 60a using a binary file 
delivery senrer 12. Figure 15 provides a functtonal btock diagram depicting a portable document delivery system 160b 
using two binary file delivery servers 12a and 12n communicating over the Internet. 

To address the limitations of the Web and electronto mail, in addrtton to providing addittonal services, the portable 
document delivery system 160 includes server software which runs on lop of eodsting electronto maU, http server soft- 
ware, and database systems. Thus, the portable document delivery system 160 combines industry standard solutions 
for the electronto mail. Web. and database to enable corporations and users to direct the delivery of documents to recip- 
ients. 

The following disclosure elaborates on the requirements for a universal document delivery solution, as well as the 
specific components of the portable document delivery system 160. 

The portable document delivery system 160 combines three basto components to provide a solution to universal 
document delivery. 

1) Portable Document Send Client. A portable document send client (PDSC) 192 integrates all desktop applica- 
tions 190 directiy with the portable document delivery system 160. The PDSC 192 is not required for all embodi- 
ments of the invention. Publishers who simply wish to leverage the BFD server 12 directiy are free to do sa The 
PDSC 1 92 is intended for the standard corporate computer user who requires a point-to^int to the delivery prob- 
lem. 

2) Binary nie Server. The binary file delivery server 12 works on top of Internet standards to deliver documents 
to recipients. The BFD sender 12 can be invoked transparentiy through the portable document send client (PDSC) 
192, a can be invoked and customized directly using a senrer configuration user interface 198. 

3) Portabto Document Receive Client The portable document receive client (PDRC) 1 94 Is the software conpo- 
nent which recipients 22 of documents utilize to receive, view, and print documents. Recipients 22 who do not have 
the PDRC software 194 will be given links to access the software cfirectiy over the Internet. In most cases, the 
PDRC 194 will behave simply as a Netscape NAVIGATOR^ Plug-in or a Microsolt Active)(~ control or a Java 
Applet, thus directiy integrating ttie PDRC 194 with the redpienfs existing browsers. 
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Figure 18 Hlustratee how a portable document send client application and a portable document receive client appli- 
cation are used in the invention. Figure 19 illustrates how a server configuration user interface application is used in the 
invention. 

Portable Documerrt Delivery System Requirements. At the most basic level, a document delivery solution must 
enable documents to be directed to customers by the producers of those documents, or Toushed". The portable docu- 
ment delivery system 1 60 is designed so that different types of redpients operating on different computer systems, with 
different operating systems, E-mail systems, and document types can all benefit from receiving, reading, and using 
electronic portable documents. The various design parameter categories that the portable document delivery system 
160 Is adapted for includes primary computer systems (e.^. PCs. WbrKstations. Servers), primary operating systems 
(e.^. Macintosh, Win 3.1 . Win "95. fslT. Unix. OS/2), electronic mail systems (e.^. Microsoft. cc:Mail. Qroupwise, Motes. 
Eudora). document types {e,g. paper. Postscript Quark, WordPerfect, ExoeQ. and user types (e.^. MIS. Legal. Finan- 
cial. Consumers/Home. MarketingCommunication (MarCom)). 

A unique aspect of the portable document delivery system 160 is the level of compatibility the solution provkies with 
all computer systems, operating systenrs, electronic mail systems, and document types. In one embodiment of the 
invention, the sender 16 and the receiver 22 of a document are both connected to the Internet In a prefen-ed embodi- 
ment of the inventton, the portable document delivery system 160 provkJes not only an Internet delivery solution, but 
also backward compatibilrty with facsimile machines 172 and printers 178. as well as fomwd compatibility with future 
distriftxrtion print architectures. 

Universal Delivery. Delivery solutions must enable users to distribute documents to anyone, whteh requires sup- 
port for a variety of computing platfewms. compatft>ility with facsimile 1 72. and compatibility with future distrixjted print- 
ing architectures. The portable document delivery system 160 can support the conversion and delivery of oonplex 
postscript files. Documents can be delivered to any recipient 22 who has an E-mail account and access to the Internet, 
regardless of the rectpi^'s platfonn or E-mail system. 

Security. Typical applk:atx)ns of document delivery require complete security from the origin of the document com- 
plete to the destinatton. This requirement becomes more pervasive as documents begin to travel across open and wide 
area networi®. The portable document delivery system 160 emptoys several levels of security. The Portable Document 
Send Client 1 92 authenticates and creates a secure socket to ipload Information to the server 1 2. Thus. non-BFD serv- 
ers cannot intercept documents. Additionally. The PDSC 192 altows the sender 1 6 to use private and or public encryp- 
tion to guarantee that only the intended recipients of a document can access those documents. Even in cases where 
encryption Is not used, the portable document delivery system 160 includes sophisticated algorithms to prevent unau- 
thorized users from accessing documents. 

Account Management Services. In many Instances, document delivery applicatkm cater to businesses where 
each sender 16 or rec^ent 22 of a document must be maintained. ConskJer the case of periodically delivering the doc- 
uments to the same group of a hundred thousand redpients 22. The sender 1 6 of the document requires tools to i|)date 
and manipulate the database of the large sut)scriptkm/ d»tributk)n base. 

The portable document delivery system 160 enables publishers 16 to create accounts on BFD sen/ers 12 and then 
associate transacHons with specific accounts 132. 134, 136. Ihe system also enables publishers to consdktate several 
user accounts into a single billing account 134. Additionally, it allows publishers to associate a specific billing code with 
transactions which may be consolkiated in transactton reports. For example, a law f inn couU create an account and 
then a billing code for each client, associating a billing code and account each documenfs transaction. The porta- 
ble document delivery system 160 maintains and updates the account information automatically. A portable document 
delivery system 160 reporting engine then allows the user to create a report for a given account or 16r a spedfic billing 
code. Such a scheme fadlitates client management as well as billing. 

"nransaction Management Services. Related to account management is the requirement of transaction manage- 
ment. Not only is it necessary to maintain the database of senders 1 6 and redpients 22 of documents, it is also neces- 
sary to provide services to manage the transactton of sending documents. For exanpie. a sender 1 6 m^ want to know 
If the document was actually delivered and actually received, and perhaps who received the document. In many 
instances, the pubUsher 16 would like to charge postage for delivery and wiD therefore require services to maintain and 
update accounting information assodated with the delivery transactions. 

The portable document deliv^ system 1 60 is able to create logs associated with each send transaction, and main- 
tain these logs- Each transadton. or document send operatton is assodated with a spedfic accoimt. Users 16 can 
query transaction information directly from the server. 

Reporting. Account and transaction management provides no value unless sophisticated means of reporting are 
provkled. For example, users 16 can be provkied with a fuU report of a given transactton. induding such information as 
which documents were delivered to whom, how many users have confirmed delivery of the document, or tor billing pur- 
poses, the costs associated with the transaction. 

Scalability and Bandwidth. Because of the large scope and appllcatton of document delivery applicattons. the 
portable document delivery system 160 is capable of expanding its capabilities to servtoe millions of documents or 
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recipients 22. Several aspects of the delivery process occur in real time, while other aspects may be deferred or sched* 
uted. In many cases, the portable document delivery system 1 60 dynamically extends the amount of bandwidth or sets 
of servers 12a-n deployed to achieve the necessary throughput for document delivery 

The portable document delivery system 160 is scalable to conform with user requirements. The server software is 

5 designed to support the sending of maiions of documents per day. and is able to exploit whatever bandwidth has been 
dedicated to a given server. Fbr example, one current BFD server 12 effectively utilizes 10 Megabit/second bandwidth. 
The various processes running on BFD servers 12 operate asynchronously, thus allowing for optimal performance on 
muttii)rocessing servers 12. as well as sophisticated scheduling of the servicing of a given transaction. Special care is 
taken to operate in real time, particularly for the access of documents from the server 12 by recipients 22. 

10 BFD servers 12 can also distribute work loads across other servers 12a-n. A preferred embodiment of the invention 
allows individual processes running on a single server 12 to be distrtouted aaoss a collection of servers 12a-n. In this 
embodiment, account management processes could run on one sender (e.^. I2d), while the logging, reporting, trans- 
action managem^, send, propagate, and retrieve processes run on another server {e.g. 12h). 

Portable Document Send aiem SpecHication. The Portable Document Send Client (PDSC) 192 allows any 

IS computer user Id distribute documents directly from the desktop of any personal computer, such as a PC or Macintosh 
computer. The PDSC 192 integrates directly with all applications 190 through the uses of virtual printer devices, thus 
enabling the PDSC 192 to be conrpatl)le with all applications 192 and formats. Importantly, because the PDSC 192 Is 
integrated directly with portable document technology, the sender 16 of a document need not make assumptfons about 
the capabilities of the intended recipient 22 of the document 

20 The PDSC 192 allows two primary modes of usage: print or Uag and drop". By print a sender 1 6 can simply select 
the print option from any applicatfon 1 90 and trigger the sequence of events to generate a portable document, and then 
address and send that document. From the user^ perspective, they simply select the print command and are then 
prompted for the destination of the document using standard addressing interlaces and address books. A Mlaosoft 
Mail"^ user, for example, would be prompted with the standard Miaosoft Mail'^ addressing dialog to direct where adoc- 

25 ument may be sent After selecting the destination of the document the PDSC 192 automatically connects to a BFD 
sender 12 and securely uploads the documents 166 and the intended list of recipients 22. as well as any other attributes 
selected to customize the send. IDrag and Drop" usage allows users 16 to avoid launching applications and printing to 
send documents: the document may simply be dropped on a PDSC 192 send icon, which is accessible from the 
sender's desktop 1 64. 

30 Additionai functionality and customization is one dick away During the addressing process* users 16 are free to 
customize the options of their send t)y invoking advanced options. By default each send will reuse the existing param- 
eters fbr sending documents. Users 16 can also use the advanced options user interim 193 to customize their delivery 
options, including, for example, security options and receipt requirements. For example, if the user 16 desires to cus- 
tomize the security options, including private and or public key encryption, the user simply checks a "Public EncrypT or 

35 -Private EncrypT option. Similarly, the user can select the "Notify on Receipr optton. thus informing the BFD server 12 
to confirm delivery when the document is actually received. 

BFD Server Configuration Options and User Interftee. The BFD Server 12 can be configured and customized 
directly from a sender desktop 164. The access to the BFD sender 12 from the desktop is achieved using an HTML 
forms user interface. This user interface exists to give server administrators access and control over the advanced 

40 options of the BFD server 12. For axanple. a server administrator might update the database of the 100,000 recipients 
who are intended to receive a specific document and then directly invoke the send of the document to those recipients. 
The sender administrator might generate a report regarding the send transactfons which occurred during the previous 
week 

To access the BFD sen^r 12 from the desktop 166, a user 16 nujst have a special account created on the BFD 
4S server 12. which is created ahead of time by the BFD server 12. Additfonally, accessing the BFD sender 12 over this 
account requires several fayers of authentication and security, thus preventing unsolicited access. 

The Sender Configuratfon User Interface 198 aUows the user 16 to access and control the sender settings, which 
may include transactfon management account management, reporting fadlHies, direct upload and downfoad of docu- 
ments to distribute, direct manipulation of recipient lists, and direct access to send options. 
50 Portable Document Receive Client Ihe recipient 22 of a document can utilize the portable document receive cli- 
ent (PDRC) 194 to access and manipulate documents which were sent to the recipient 22 by the portable document 
send Client 192 or by the BFD server 12 directly via the BFD sender administrator. In the event that the recipient 22 of 
a document does not already have a PDRC 194, the software may be downkjaded and insfalled directly from the Inter- 
net The architecture of the portable document delivery system 1 60 simplifies this process, and employs dedicated soft- 
55 ware and scripts. In addition to advents in new browser architectures to enable first-time recpents 22 to be one dick 
away from accessing the necessary software to receive documents. 

The most basic case of the portable document receive client 194 can simply function as browser extension, such 
as a Netscape NAVIGATORT" plug-in or a Microsoft ActiveX^ control. Fbr other users, the PDRC 194 will behave as 



11 



EP0869 652 A2 



a stand alone application which works as a helper appiication. 

A thW application exists for portable document delivery system 160 customers who prefer direct access to the port- 
able documents from the recqaients desktop 1 70. In this configuration, a dedicated portable document receive client 194 
can be downloaded directiy from the Internet This component will continually monitor the activity of the portable docu* 
ment delivery system 160, and will automatically extract any incoming portable documents from BFD servers 12. and 
open them for immediate document communication on the computer desktop 1 70 of the recipient 22. 

Recipients 22 of portable documents from the portable document delivery system 1 60. depencfing on the send con- 
figuration options, will be allowed to view, search, print, archive, or export information from ttieir documents. Documents 
distributed using Envoy"^ or Aaobat^ in conjunction with the portable document delivery system 160 will presence 
complete visual fidelity and may be produced on high resolution output devices with the highest of quality 

Figure 20 illustrates how a document can be sent by the fax gateway 56 of a BFD server 12 to a printer 1 78. Figure 
21 illustrates how a document can be sent by tiie department gateway 202 of a dedkated corporate BFD sen/er 200 
through a LAN 204 to a department printer 1 78. 

Private, 'nrackabie URLs for Directed Document Delivery. This embodiment of ttie invention provides a unk|ue 
means of delivering documents electronically. Importantiy, this embodiment of the invention enables a number of value 
added services, in addition to basic document delivery, induSng but not limited to tracking and security. 

The invention provUes a document delivery architecture which dynamically generates a private Unifonn Resource 
Locator (URL) to distribute Information. Each private URL CPURL^ unk^uely identifies ttie intended recipient of a doc- 
ument, the document or set of documents to be delivered, and (optionally) ottier parameters specific to tiie delivery 
process. The intended recipient of a document uses ttie PURL to retaieve a document (or documents). The server, upon 
retrieval of the document, customizes the behavfor of the retrieval based upon attributes included in the PURL as well 
as log infomiation associated wtth ttie retrieval in a data base. This architecture and usage of PURU enables secure 
document delivery and bracking of document receipt 

The World WkJe Web C^eb") enables consumers to retrieve content from Web servers using Web browsers. In 
short, consumers pull content from ttie W^ E-mail enables producers d content to send that content to consumers. 
In other words, producers push content witit e-mail. E-mail Internet servers, as well as the SMTP protocol (sinplified 
mail transport protocol) which governs ttie behavfor of Internet severs, are Qmited a«)abilitie8 ttiey provide to users of 
the Internet. For exanple. SMTP e-mail servers do not know anyttiing about binary file types, tracking, or security. 

The Web and the associated HTTP protocol, by contrast, provfoes a flexfole protocol ttiat enables ttie efffcient. 
secure transmission of binary information. HTTP, howmr. Is a pull, consumer driven protocol, and hence a producer 
or sender of information cannot rely on HTTP exclusively to direct ttie delivery of information. 

- By combining HTTP for ttie delivery, as well as using SMTP/e-mail for notification. It is possible to buifo a solution 
that allows ttie producer to be ttie driver, or to push, but that does not sufl^ from ttie iimitatfons and legacy issues asso- 
ciated witii SMTP/email. 

PURU are temporary, dynamfoally generated unifonn resource locators which unk^uely identify ttie intended recip- 
ient of a document and ttie document itself, as well attributes associated witti ttie delivery of a document. PURU avoid 
attaching information to e-mail messages to send documents, but rattier attach a general reference to a document to 
be sent and ttien enable ttie recipient to access a document via ttie reference. 

When ttie recipient accesses ttie document by using ttie reference, a server can intercept ttie request to access ttie 
document and provide value added services, such as tracking and seojrity For example, a user can include a key in 
the PURL ttiat serves to unlock a document on a sender, pertiape decrypting an enaypted document. Or, a user can 
include a unique Identification number in ttie PURL ttiat identifies ttie recipient In ttiis case, ttie term can notice ttiat 
a specific indivklual has accessed a specif fo document, can note ttiat in a data basa and can make ttiat information 
available to ttie sender. This embodiment of ttie invention can ttierefore provide document traddng. 

Figure 22 is a block diagram which depicts a document delivery system that includes private, tradable URU for 
directed document delivery according to ttie invention. A document 31 0 is forwarded from a sender 300 to a server 315. 
TTie sender temporarily stores the document The server dynamically generates a URL for each intended recipient of 
the document In addition to encoding user information and docunent information witti ttie URL, ttie server also 
encodes delivery parameters, or ttansaction identifiers in ttie URL Each geneiatod personal URL (PURL) is ttien for- 
warded to each intended recipient 320. The recipient is notified 325 ttiat a given document has been sent to him. This 
typically has the form of an e-mail message which Includes a private URL The recipient, using ttie PURL 330 and ttie 
Web. accesses ttie document 

When the recipient accesses ttie document via ttie PURL ttie recipient presents ttie PURL to ttie server. The 
server then has ttie opportunity determine ttie next set of actions. For example, ttie server couU notice ttiat ttie PURL 
specifies ttiat a password must be presented before ttie elecfronic document referenced by ttie PURL can be accessed. 
The sen/er may also Wentify ttie specific recipient accessing ttie document by ttie PURL and log the fact ttiat ttie spe- 
cific recipient has attempted access the specific document, again all foentified by ttie PURL The server may also fog 
the fact that the entire document was delivered successfully. 
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Accadingly, a data base maintained on the server has a full log describing the following, for example: 

• Who accessed the document; 

• When they accessed the document; and 

• Whether they successfully accessed the document 

This information which the server has logged can then be reported back to the sender of a document Hence, using 
a corrfoination of e-mail for notification, the Web for delivery, and private URLs to identify recipients and documents, a 
delivery sen/er can be constructed to track documente and report the delivery state of a document back to the sender 
The actual implementation of such system may be in accordance with the system herein described in connection with 
Rgures 3-21 . or it may take other forms as appropriate. 

In other embodiments of the invention, the server can log other types of information. Thus, the server can log the 
IP address associated with a given recipient who is retrieving a document. The server can also log the IP address of 
any subsequent accesses to a given document with the same PURL Thus, the server couki prevent multiple IPs from 
accessing the same document using the same key. Altematively. the sen/er coukI provkle a list to the sender containing 
IP addresses which accessed a spedf k; document intended for a specific recipient 

The above described architecture for delivery also facilitates security. A document can remain encrypted on the 
server untii a recipient presents a valid key to access and deaypt a document. This key is presented as encoded in part 
of the PURL Alternatively, the PURL specifies that a key must be retrio^ed. in which case the sen/er requires that the 
recipient present a unk^ue password to decrypt the document m the first case, retrieval of the encrypted document is 
a one-step, automatic process because the key is encapsulated in the PURL 

PURL Implementation. 

Rrst consMer the potential constructfon of a PURL The fblfowing diagram outlines one spedfto example of a 
PURL: 

http://posta.tumbleweed.com/cgi4po8ta.dll? pu • 0-233'33982-FIAAAV4 
The above PURL denotes the folfowing: 



Value 


Meaning 


httpy 


Use the HTTP protocol to access. 


posta.tumbleweed.com 


Name of the HTTP server. 


cgi/posta.dll 


Name of HTTP server extension. 


pu«0 


Doni use a password. 


233 


Store item Identifier. 


33982 


Recipient foentif ier. 


FIAAAV4 


Key to access the document. 



With further reference to Figure 22. it should be noted that a PURL 302 is shown having varfous fields. These f ieWs 
include a password identifier 331. a store item kientifier 332. a recipient kJentifier 333. a document key 334. and any 
other optional fiekls that may be desired 335. These fiefos are dtecussed in greater detail below. 

Password Identifier. A password identifier specifies whether a password is rec^ired to access a given document. 
In this case, the value "0" indicates no password is required. A value of ''I * indicates a password is required. 

Store Item Identifier. A store item kJentifier unk^uely identifies which document a given recipient desires to obtain. 
In this case, the value "233" provkles an index into a sparse table on the sen/er. identifying a value which, e.g. Uentif ies 
where a given document resides on the sender and/or what a document is named. 

Recipient Identifier. A recipient identifier unquely identifies the intended recipient of a given document. In this 
case, the value "33982" provides an index into a sparse table on the sen/er. The value at this table index contains recip- 
ient information. 

Document Key. The document key validates the PURL itself. In this case, the key is a randomly generated number 
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associated wtth the given recipient and store identifiers. The key is used to validate whether the given recipient identi- 
fication number 18 valid, whether the given store identification nunijer is valid, and whether the given recipient with the 
given store identification numi>er should be granted access to a document In other embodiments of the Invention, the 
key also encodes an index into a table which contains the validation infbmiation, as opposed to encoding the validation 
Information itself. 

importantly, the server has a Web extension, enabling the HTTP processing of a document to be extended to pro- 
vkJe customizatfon. Thus, the recipient accessing the document goes through an HTTP server extension to communi- 
cate with an HTTP server. This extenston. for example, can decide to grant access to a document in which case it 
presents the user with a new PURL which facilitates transmission of the specific document 

The server can use the above attributes and values of a PURL to customize the behavior of document delivery. 
Specifically, the server executes the fottowing steps to deliver the document and record the delivery transaction: 

• Decode the PURL into its various parts: 

• Valkiate each component of the PURL: 

• Authenticate the PURL using the key: 

• Determine which user Is accessing the document by using the Recipient 

• Determine which document the user is accessing by using the Store Item 

• Determine whether the document given the above, requires addrtk)nalff^ 

• Deliver the document to the recipient; 

• Log all attributes of the transactiori. including, e.^ time of access, success of transmission, and IP of recipient. 

Once information has been logged in a data base running on the server which records transaction infomiation, this 
data can be accessed by the recipient and can even be dynamically transmitted back to the recipient. For example, a 
given publisher (sender) asks the server's data base for all documents which have been delivered to a specific recipient. 
The publisher asks the server to generate a report of the status of a given document sent to ten peopla The server 
reports back, for example, that the document has be«i sent to all ten people at a spedfic time, but only three of the 
people have actually retrieved the document. Each document retrieval may include the specific tinrie the document was 
accessed, the time it was accessed, and whettier it was accessed completely and successfully. Hence, dynamically 
generated PURLs as broadcast over email enable a robust means of tracking tiie delivery of documents over wide area 
networks. 

Although the electronic document delivery system and its methods of use are descrtoed herein in connection witii 
use in the Internet, the invention may be applied to any of a wide variety of networks, including internets. Intranets. 
LANs and WAfsis. or any combination tiiereof. as desired. As well, the invention may be applied to a wide variety of com- 
puter platlbrms, communication protocols, portable document fonnats, or any coni)ination thereof, as desired. 

The Invention provkdes a method and system for secure document delivery over a wkle area nelwortc. A document 
Delivery Server dynamically retrieves a pubfic key of an intended recipient of a document then uses the public key to 
encrypt either a document or the secret key of the document The sender delivers the encrypted document to an 
intended recpent over a wkJe area network such as ttie Internet. The intended recipient decrypts the document using 
the private key associated with the public key. The invention permits only an intended recipient to gain access to a spe- 
cific document and therefore provides a mlqjB level of security for document delivery. 

For the purposes of ttie invention, tiie tenn document includes any contiguous collection of data, including a stream 
of data, a video, audk) data, an animation, a formatted document such as HTMU PDF. or Envoy, or a data base. While 
the preferred embodiment of the invention is adapted for use in document transmisskm over the Internet the invention 
is equally appik»ble to ottier wkie area networi®. 

Furttiemriae, while the preferred embodiment of ttie invention discloses tiwismission of a document to a recipient 
computer, the invention is operable fbr document transmisston to any intended recipient maintaining, or having the abil- 
ity to dynamically generate, a private^ubUc key and to use the private key to decrypt a document encrypted with tfie 
corresponding publk: key. An intended recipient tiierelbre. includes, lor example, an Internet user of a desktop compu- 
ter, printer, fax machine, personal digital assistant, or networic conputer device. 

Similariy. while the sender of a document is preferably a desktop computer, the sender also includes any device 
capable of encrypting a document and communicating wittt ttie Delivery Sender, such as a network conputer device. In 



14 



EP0 869 652A2 



an alternative emtxxiiment of the invention, the document is encrypted by the delivery server In this embodiment, the 
sender Includes any device, such as an Internet browser device. Internet telephone device, personal digital assistant, 
or fax machine, that can transmit a document to the Delivery Server for encryption and transmission to the intended 
recipient 

Figure 23 is a cfiagram of a system for dynamic sen^r document encryption, according to a first preferred enrted- 
iment of the invention. A document staed on a desktop computer, the sender 1032. is to be transmitted to another com- 
puter, the intended recipient 1034. In this first preferred embodiment, the document is stored In Portable Document 
Format (PDF). However, in alternative embodiments, a document may be stored in any appropriate format Portable 
Document (PD) fbmiats are required for distributed print and fax solutions. However. PD formats are not required for the 
invention. 

The document is sent from sender to recipient via the Delivery Server 1036. In this first prefen-ed embodiment of 
the invention, the Delivery Server is directed by the sender to communicate with a certificate authority database server 
1038 to retrieve the intended recipient's public key (certificate). The Delivery Server dynamically queries the certificate 
authority and retrieves the public k^. The public k^ is transmitted to the Delivery Sender and from there to the sender. 
In alternative embodiments of the invention, the Delivery Server retrieves the intended redpienTs public key from the 
intended recipient's desktop computer, an Internet senw. or from an intranet sen/er connected to the intended recpi- 
enf 8 desktq) computer. 

In the first prefenred embociment of the inventbn, the sender encrypts the document using a seaet key and uses 
the public key to encrypt the secret key. The document and encrypted seaet key are then transmitted to the intended 
recipient The secret toy is decrypted with the intended redpienTs private key and is then used to decrypt the docu- 
ment. 

In an alternative, equally preferred embodiment the sender uses the public key to encrypt the document. The 
encrypted document is then transmitted to the intended recipient and decrypted using the private k^ associated with 
the public key. 

Figure 24 is a f tow chart of the set of operations fbr dynamic server document encryption, according to a first pre- 
ferred embodiment of the invention. In the example, the sender encrypts the document 1040 using a seaet key. Such 
seaet key includes any appropriate enayption scheme known In the prior art. The sender then contacts a Delivery 
Server 1045 to query 1050 the public key associated with the Intended recipient The Delivery Server retrieves this cer- 
tificate in real time 1055, fbr exanrple from the data base of a certificate authority, and transmits the certificate back to 
thesender1060. 

In the event that the certificate authority returns no certtficate. the Delivery Server dynamically generates a new 
certificate Ibr the recipient To do so. the Delivery Server forwards a dynamk^lty generated URL in an e-mail message 
to the recipient. Recipient access of the URL dynamically retrieves a Java Applet or Plug-in. which is automatically 
downloaded to the recipient's system. This applet or Plug-in then runs on the Recipient system and constructs a pri- 
vate/|9ublic key pair. CBenerating a private^ic key pair on a tocal machine is not spedTic to this inventton and is doc- 
umented In a number of sources. 

The applet or phig-ln next fbnwards the public key to the Delivery Server. The server, using properties of the gener- 
ated URL. identifies the e-mail address of the recpient Thus, the generated piMc toy has the property of having 
authenticated the e-mail address of the recipient, as the URL to invoke the key generation has or^y been fbnvarded to 
a specific e-nuiil address. The server combines the e-mail address and publk: key into a certificate and returned to the 
Send Client or used ksy the senrer to encrypt the document or seaet key. The Delivery Server, using LDAP or a similar 
protocol, may communicate the certifkste to the certiftoate authority. Altematively. the Delivery Server simply may 
maintain a local database or dynamically generated certificates Ibr future use. 

Upon receiving the public key from the Delivery Server, the sender encrypts the seaet key 65 with the put)lic key. 
In an altemative, equally preferred embodiment of the invention, the sender does not encrypt the document until the 
public key has been received. Because the document is not encrypted if the public key is not authenticated, this embod- 
iment minimizes processing time when a pubfic key cannot be retrieved. 

The sender then fonwards 1070 the enaypted document, the address of the intended recipient (fa example an 
email address), delivery Instructions, and the encrypted seaet key to the Delivery Server over a secure channel. Thus, 
the document does not leave the Sender until the document has been encrypted with the seaet key and the seaet key 
has been enaypted with the intended recipient's public key. The Delivery Sender then delivers 1 075 the encrypted doc- 
ument and seaet key to the intended recipient. The intended recipient using the private key associated with the public 
key. deaypts the seaet key 1080 and uses the seaet key to decrypt the document. Such scheme prevents unauthor- 
ized access to the document since the document can only be accessed by the owner of the public key. 

Figure 25 is a f tow chart of the set of operations for dynamic server document encryption, according to an alterna- 
tive embodiment of the invention. The sender notifies the Delivery Sender 1090 that the sender intends to send a doc- 
ument to a given recipient The Delivery Server queries 1095 the certificate authority to obtain the intended recipienrs 
public key, whtoh is returned 1 100 to the Delivery Sender. 
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In this embodiment the Sender does not encrypt the document Ixjt forwards the document 1 105 to the Delivery 
Server over a secure channel The Delivery Sender then enaypts 1 1 10 the document using a sewet key. The Delivery 
Server uses the retrieved public key of the intended recipient to encrypt 1 1 15 the seaet key. and then foiwartte the 
encrypted document and secret key to the intended recipient 1 120. The intended recipient uses the private key to 
decrypt the secret and then uses the secr^ key to decrypt the document 1 1 25. 

Altematively. the Delivery Sen/er may use the pubUc key to encrypt the document The encrypted document is then 
transmitted to the recipient. 

In the prefen-ed implementation of the invention, the sender is connected to the intended recipient via a Delivery 
Server, all running over a wide area network, such as the Internet The sender is preferably a computer using software 
refened to herein as the Send Client. 

The Delivery Server Is responsfldle for determining the public key of a given recipient and forwarding that key to the 
Send Client. The Delivery Server is also responsible for delivering the encrypted document and secret key to the 
intended recipient 

The Send Client initiates the delivery transactkxi by first klentifying the document to be delivered, any delivery 
parameters, and the set of intended recipients to receive the document. Delivery parameters include such options as 
the scheduled delivery time, security options, urgency of the delivery, presentation parameters for the delivery, and 
receipt notification. 

The Send Client then Initiates a dialog with the Delivery Server and encrypts the document ¥wth a secret key. The 
dialog and encryptfon steps may be peridnmed simultaneously or sequentially, depending upon the sender's hardware 
and software configuration. In the diatog, the Send aient forwards to the Delivery Server the intended recq>ient(s) of a 
given document The Send Client requests that the Delivery Server contact the Send Qient once the public key has 
been acquired. 

The Send Qient expresses the identity of the intended recipient(s) of a given document in different ways. In the pre- 
ferred entoiiment of the invention, the Send Qient uses the eledronic mail (email) address of the intended recipient 
as the identifier of the intended recipient However, the Send Qient can also identify the intended redpient with an alter- 
native kJentif ier. such as a driver's license number, a social security number, an abstract identifier, a synfool name, or a 
fax number. 

The Delivery Server uses several techniques to obtain the certificate for the Intended recipient. In the preferred 
embodiment of the invention, the Delivery Sender contacts a certificate authority data base server, presents inlbrmatfon 
identifying the intended redpient. and asks for the intended rec^jienTs public key. The fawantion may therefbre be used 
to obtain information from certificate authorities that maintain pubGc key data bases that can be accessed dynamically 
over a programmatic Interfoce (queried) In real time. 

The invention is implemented using any appropriate means for a Delivery Server to query a public key of an 
intended recipient in real time without user intervention. Thus, the specific protocol and means of accessing the public 
key data base are not significant for the invention. The public key data base is prelMbly accessed using the Internet 
Ughtweight Directory Access Protocol (LDAP) standard devetoped by the University of Mfohigan in conjunction with the 
Intemet Engineering Task Forca LDAP servers provUe directory and other sendees. Using LDAP protocol, a given 
sender may be queried, and infonnation maintained on that server may be retrieved over an electronic networit LDAP 
servers can be queried directly using standard Internet protocols. Alternative embodimente of the invention use. for 
example. SQL Queries with different connectivity protocols Including RPC (remote procedure caU). 

The certificate authority date base server and the Delivery Server may be either the same or separate servers. 
Maintaining both the certificate authority date base and the Delivery Server on the same server Is advantegeous for a 
dedicated application of document delivery which does not require access to a general date base of certificates. For 
example, a corporation may maintain a database of empfoyees' public keys on the same server used for Intemet com- 
munications. The same sender Is therefore used as the certificate authority date base and as the Delivery Server fbr 
interoffice communication within tiie company. 

For embodiments in which tiie certificate authority date base sender and the Delivery Sender are separate, the 
Delivery Sen^ may maintein a cache or local copy of recentiy queried certificates. Use of such cache saves time in 
future queries fbr tiie same redpient and certificate. 

The invention supporte documafn delivery to one or more recipients. For multiple recipients, the process discussed 
above is applied In batch mode. An ordered list of Intended recipienis is fomvarded to tiie Delivery Server, and the Deliv- 
ery Sender returns a conesponding ordered list of certificates. 

The invention may also be used to send multiple documents from sender to redpient(6). In such case, a single 
secret key is used to encrypt each document. Once tiie Delivery Sender has returned a certificate containing each redp- 
lent's public key. the single secret key is encrypted witfi the retrieved public key(s) of ttie intended rec(pient(s). For each 
redpient. the Send Client fonwirds an encrypted seaet key and tiie encrypted document(s) to tiie DeOvery Server, 
along witii the intended redpient address and delivery parameters. 

The Delivery Server then fonwards to each recipient ttie combined encrypted seaet key and document(s). The 
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recipient device uses software Known as the Receive Client. The Receive Qient is currently Implemented as a Java 
Applet as well as a plug-in to standard internet browsers. Java is a programming language developed by Sun Miaosys* 
terns of Mountain View, CA. However, the Receive Client may also be implemented using any other programming lan- 
guage that is capable of receiving and decrypting the transmitted secret key and document(s). 

When implemented as a Java Applet, the Receive Client is distributed dynamically from the Delivery Server to the 
intended recipient's system. The Receive Qient uses the private key to decrypt the secret key. TNs decrypted secret 
key is then used by the recipient to deaypt the document(s). 

In the prefered embodiment of this inventk)n, the Receive Client accesses the encrypted secret key and document 
from the Delivery Server using Hypertext Transmission Protocol (HTTP), the standard internet delivery protocol. How- 
ever, the Receive Client may access the Delivery Sender using any other appropriate protocol. 

When using HTTP, the Receive Client is sent a uniform resource locator (URL) containing the address of the doc- 
uments and key to be defivered. In the preferred embodiment of the invention, the document(s) and secret key are pack- 
aged into a single file or stream of data, which is delivered intact to the Receive CUent using HTTP The Receive Client 
is thereby given maximal flexibility to retrieve the package and decrypt it from the recipient(s) web browser. The recipi- 
ent may use any web browser a other software application that Is capable of receiving the data transmitted over the 
wide area network. 

Although the inventk>n is described herein with reference to the preferred embodiment, one sMIIed in the art will 
readily appreciate that other applications may be substituted for those set forth herein without departing from the scope 
of the present invention. 

The source code for the Send Client the Receive Qient and for the Delivery Server software can be readily con- 
figured by one skilled in the art using well-known programming techniques and hardware components. Adcfitionally. 
Send Client and Delivery Server functtons may also be accomplished by other mear«. including integrated circuits and 
programmable memory devices such as an EEPROM. 

The implementation of the dynamic server document encryption discussed above with regard to the prefen-ed 
embodiment of the invention is only one possible implemenlatkm. Alternate embo d i m ent s m^ use other inplementa- 
tions consistent with the teachings of the inventtoa 

The Receive Client may be configured to direct a document to another devtoe. For example, a decrypted document 
may be sent to a printer or a fax machine. 

The invention may use any appropriate encryption scheme for the secret key, pubik: key, and private key, including 
the RSA and Verisign schemes. 

Although the present invention has been described in detail with reference to a particular preferred embodiment, 
persons possessing ordinary sKII in the art to which this invention pertains will appreciate that various nrxxJif ications and 
enhancements may be made without depart^ from the spirit and scope of the claims that folkiw. 

aaims 

1 An apparatus for delivering an electronic document between a sending computer (16) and a receiving computer 
(22). comprising: 

a sen/er (12) interposed between said sending conputer (16) and sakl receiving computer (22). wherein when 
saki electronic document is fbnwarded to said server (12) from said sending computer (16) and said server (12) 
dynamk»lly generates a private Uniform Resource Locator fPURL") to distribute saki electronk: document. 

2. The apparatus of Qaim 1, wherein saki PURL unqueiy kientifies an intended recipient (22) of saki electronic 
document and. optionally, other parameters specific to said electronic document delivery. 

3. The apparatus of Qaim 2. wherein saU intended recipient (22) of said electronic document uses sakJ PURL to 
retrieve saki electronic document 

4. The apparatus of Qaim 3, wherein sakf server (12), upon retrieval of sakj electronk: document, customizes the 
behavkK of said retrieval based upon attributes included in saki PURL and. opttonally. log information associated 
with sakJ retrieval in a data base, to enable secure document delivery and tracking of document receipt. 

5. The apparatus of one of the preceding claims wherein saU sender uses HTTP for delivery of saki electronk; doc- 
ument and SMTP/e-mail for notif icatton of arrival at saM server of said electronic document. 

6. The apparatus of one of the preceding claims. saU PURL comprising: 
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a temporary, dynamically generated uniform resource locator which uniquely identifies an intended recipient 
(22) of said electronic document and, optionally, said electronic document itself and attrikxjtes associated with 
delivery of said electronic document 

7. The apparatus of one of the preceding claims, wherein said PURL attaches a general reference to an electronic 
document to t>e sent, and enak)les a recipient (22) to access said electronic document via said referenca 

8. The apparatus of Claim 7, wherein said server (12) intercepts the reguest to access said electronic document 
and provides a value added sen^e in connection with said access, when said recipient (22) accesses said docu- 
ment by using said referenca 

9. The apparatus of one of the preceding claims, said PURL further comprising: 

a key that unlocks a document on said sender (12). 

10. The apparatus of one of the preceding daims, said PURL further comprising: 

a unique identif icatkm numk)er that identifies a recipient of said electronic document 

11. The apparatus of Qaim 10. wherein saki server (12) notices that a specific individual has accessed a specific 
documem and notes that in a data base to provide document tradong. 

12. A document delivery system for delivering an electronic document (310) between a sender (300) and at least 
one recipient (320). comprising: 

a document sen/er (315) that temporarily staes said electronic document (310). wherein said senrer (31^ 
dynamically generates a private, tractable URL fPURL") (330) for each intended recipient (320) of said docu- 
ment (310) that is forwarded to each intended recipient (320). 

13. The system of Claim 12, wherein said server (315) encodes delivery parameters, or transaction Mentifiers In 
said PURL (330). 

14. The system of Claim 12 or 13. wherein said PURL (330) comprises: 
an e-rhail message. 

1 5. The system of one of daims 12 to 14, wherein said redpient (320) accesses sakI dectronic document (310) via 
said PURL by presenting sakJ PURL (330) to said sender (315). 

16. The system of Qaim 15. wherdn said server (315) requires that said PURL (330) specifies that a password 
must be presented before the electronic document (310) referenced by saki PURL (330) can be accessed 

17. The system of Claim 15 or 16. wherein sM smw (315) ktentifies a spedfic recipient (320) accessing saU 
etectrortic document (310) with sakJ PURL (330). 

18. The system of Claim 17. wherein sakl sender (315) logs the fad that a spedfk: recipient (320) has attenpted 
access a specific document (310). 

19. The system of Qaim 17 or 18, wherein said sen^ (315) logs the fact that an entire electronic document was 
delivered successfully 

20. The system of one of claims 12 to 19. further comprising: 

a data base maintained on. or associated with. saM senmr (315) that has a fiill tog describing any of who 
accessed, said electronic document (310). when they accessed the document 010). and whether they suc- 
cessfully accessed sakl electronic document (310). 

21 . The system of Claim 20. wherein infonnation which saU server (315) has logged is reported back to the sender 
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(300) Of an electronic docunient (310). 

22. The system of one of claims 12 to 21. wherein said server (315) can log any of the IP address associated wrth 
a given recipient (320) who is retrieving a document, the IP address of any subsequent accesses to a given docu- 
ment (31 0) with said same PURL (330). or a list containing IP addresses which accessed a specif ic document (31 0) 
intended for a specific recipient (320). 

23. The system of one of Claims 12 to 22, wherein said electronic document (310) remains encrypted on said 
server (315) until a recipient (320) presents a valid Icay to access and decrypt said electronic document, wherein 
said key is presented as encoded in part of said PURL 

24. The system of one of Claims 12 to 23. wherein said PURL specifies that a Icey must be retrieved, and wherein 
said server (315) requires that a recipient (320) present a imique password to decrypt said electronic document 
(310). 

25. The system of one of Claims 1 2 to 24 . said PURL (330) further comprising: 

a pasword identifier (331) that spectfies whether a password is required to access a given document (310). 

26. The system of any of Claims 12 to 25. said PURL further comprising: 

a store item identifier (332) that uniquely identifies which document (310) a given recipient (320) desires to 
obtain. 

27. The system of any of Claims 12 to 26. said PURL further oonprising: 

a recipient identifier (333) that uniquely identifies an intended recipient (320) of a given document (310). 
26. The system of any of Claims 12 to 27. said PURL further comprising: 
a document l<ey (334) that validates said PURL (330) itself. 

29. The system of Claim 28, said document key (334) further comprising: 

a key that is a randomly generated number associated with a given recipient (320) and a document a given 
recipient (320) desires to obtaia wherein said key is used to valklate whether a given recipient (320) kJentifi- 
cation number Is vaikJ, whether a given store kJentif icatton number is valid, and whether a given recipient (320) 
with a given store klentificatk)n number shoiM be granted access to a ddcum 

30. A method for delivering an electronic document between a sender (300) and at least one recipient (320), com- 
prising the steps of: 

using a document server (315) to temporarily store said electronic document (310), wherein said server (315) 
dynamically generates a private, trackable URL ("PURL") (330) Ibr each intended recipient (320) of said docu- 
ment that is forwarded to each intended recpient; 

decoding said PURL into its component parts (302); and 

validating each component part (302) of said PURL 

31. The method of Claim 30. further comprising the step of: 
authenticating PURL (330) using a key. 

32. The method of Claim 31 , further comprising the step of : 

detennining which user is accessing a document (310) by using a recipient identifier (333) that uniquely iden- 
tifies an intended recipient of a given document (310). 
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33. The metfiod of Claim 32. further oomprising the step of: 

determining which document (310) a ueerie accessing by using a store item identifier (332) that uniquely Iden- 
tifies which document (310) a given recipient (320) desires to obtain. 

34. The method of Claim 33. further comprising the step of: 

determining whether said document (310) requires additional input before it can be delivered. 

35. The method of Claim 34, further comprising the step of: 
delivering said document (310) to said recipient (320). 

36. The method of any of Claims 31 to 35. further conprising the step of: 

logging all attributes of a delivery transaction, including any of time of access, success of transmission, and IP 
of redpient 

37. A method for secure document delivery from a sender (1032) over a wide area networli, conprising the steps 
of: 

a sender (1032) encrypting a document (1040) using a secret key (65); 

the sender contacting a Delivery server (1045) to query (1050) a pubfic key associated with an Intended reap- 
lent; 

the Delivery server dynamkxdiy retrieving the public key in real time (1055); 
the Delivery server transmitting the public key back to the sendert1060): 
the sender encrypting the secret (65) with the pubfic key; and 

the sender (1 070) transmitting the encrypted document and the encrypted secret key to the Delivery server fbr 
transmission (1 075) to the recipient 

38. The method of Claim 37. further comprising the step of the recipient (1034) decrypting the secret key (1080) 
using a private key. 

39. The method of Claim 38, further comprising the step of the recipient decrypting the document using the secret 
key. 

40. The method of any of Qaims 37 to 39. wherein the sender encrypts the document prior to receiving the pubUc 
key from the Delivery server. 

41 . The method of any of Claims 37 to 39. wherein the sender encrypts the document subsequent to receiving the 
put)lic key from the Delivery server. 

42. The method of any of Claims 37 to 41 . wherein the document is one of a contiguous cdlectkm of data, a stream 
off data, a vWeo, audio data, an animation, a fdnriatted document or a data basa 

43. The method of any of Claims 37 to 42. further comprising the step of the sender fonwarding the address of the 
intended redpient and document delivery instructions to the Delivery server. 

44. The method of any of Claims 37 to 43, wherein the wide area network is the Internet. 

45. The method of any of Claims 37 to 44. wherein the recipient is one of a desktop conputer. a printer, a fax 
machine, a personal digital assi^am. or a network computer device. 
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46. The method of any of Claims 37 to 45, wherein the sender is one of a desktop computer, an Internet browser 
device, an Internet telephone device, or a network computer device. 

47. The method of any off Claims 37 to 46, wherein the database server dynamically retrieves the public key from 
one d a certificate authority, an Intemet server, personal digital assistant the intended redpienfs desktop conpu- 
ter. or from an intranet server connected to the intended recipients desktop computer. 

48. A method for secure document delivery from a sender (1032) over a wkle area network, comprising the steps 
of: 

a sender contacting a Delivery server (1 036) to query a public key associatad with an intended recipient (1 034) 
of a document; 

the Delivery server (1036) dynamically retrieving the public key in real time; 
the Delivery server (1036) transmitting the pMk: key back to the sender (1032); 
the sender encrypting the document with the public key; and 

the sender (1032) transmitting the encrypted document to the Delivery server (1036) for transmission to the 
recipient (1034). 

49. The method of Qaim 48. further conrprising the step of the recipient (1034) decrypting the document using a 
private key. 

50. The method of Claim 48 or 49, wherein the rec^ent is one of a desktop computer, a printer (178). a fax 
machine (1 72), a personal digital assistant or a networic conputer device. 

51 . The method of any of Claims 48 to 50. wherein the sender is one of a desktop conputer. an Intemet browser 
device, an Internet telephone devk^e, or a networic oomputer device. 

53. The method of any of Claims 48 to 51 , wherein the database server dynamically retrieves the public key from 
one of a certificate authority, an Intemet server, personal digital assistant, the intended redpienTs desktop conpu- 
ter, or from an intranet server connected to the intended recipient's desMop oomputer. 

54. A method for secure document delivery from a sender (1032) over a wkle area networic conprising the steps 

of: 

a sender contacting a Delivery server (1090) to query (109^ a publk: key associated with an intended recpi- 
ent; 

the Delivery server dynarnk»lly retrieving the pubfic key in real time (1 100); 
the sender transmitting the document to the Delivery server (1 105) ; 

the Delivery server enaypting (1 1 10) thedocument with a secret key and encrypting (1 1 15) the secret key with 
the public key; and 

the Delivery server transnrvtting the encrypted secret key and the encrypted document to the intended recipient 
(1120). 

55. The method of Oaim 54. further comprising the step of the recipient decrypting the secret key using a private 
key. 

56. The method of Claim 55. further comprising the step of ttie recipient (1034) decrypting the document (1 125) 
using the ssCTet key 

57. The method of one of Claims 54 to 56. wherein the recipient is one of a desktop oonputer. a printer (178). a fax 
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machine (1 72), a personal digital assistant or a network conputer device. 

58. The method of any of Claims 54 to 57. wherein the sender is one of a desktop computer, a network computer 
device, an Internet browser device, an Internet telephone device, or a fax machine. 

59. The method of any of Claims 54 to 58, wherein the database server dynamically retrieves the public key from 
one of a certificate authority, an Internet server, personal digital assistant, the intended redplenTs desktop conpu- 
ter. or from an intranet server connected to the intended redpientisdesMop computer. 

60. The method of any of Claims 54 to 59, further comprising the etsp of: 

dynamically generating a pubfic key at said Delivery server where said recipient does not have a public key at 
the time of saki retrieval. 

61 . The method of Claim 60, satel dynantic generating step further comprising the steps of: 

fonrarding a message to saki recipient the reading of which retrieves a module that constructs a private/public 
key pair on sakI rectpienrs system. 

62. The method of Claim 61 . said dynamic generating step further comprising the step of: 
fbnwarding sakJ public key from saU redpienTs system to sakI Delivery server. 

63. A system for secure document delivery from a sender (1032) over a wkfe area network, conprising: 

• a Delivery server (1036) for querying a public key associated with an intended recipient (1034) at the direction 
of a sender (1032), the Delivery sen/er (1036) dynamically retrieving the public key in real time and transmitting 
the public toy back to the sender: 

the sender (1 032) for encrypting a document using a secret key (65). the sender (1032) encrypting the secret 
toy (65) with the publk: key and the sender (1 032) transmitting the encrypted document and the encrypted 
seaet toy to the DelivBry server (1 036) for transmisston to the intended recipient (1 034). 

64. The system of Claim 63, further conprising: 

means for decrypting the seaet key by the recipient (1034) using a private key; and 
means for decrypting the encrypted document using the seaet key (65). 
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